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(54) Content distribution apparatus, content receiving apparatus, and content distribution 
method 



(57) A content distribution apparatus for implement- 
ing copy protection when distributing digital content as 
a real-time stream on the Internet is provided. This ap- 
paratus encrypts content and distributes them to a re- 
ceiving apparatus via the Internet, and performs an au- 
thentication procedure and a key exchange procedure 
between with the receiving apparatus. The encoded 
content encoded by a prescribed encoding system is en- 
crypted (S401 ), an encryption expansion header is gen- 



erated that includes at least one attribute information of 
attribute information indicating whether or not the con- 
tent is encrypted and attribute information indicating the 
encryption system used (S403), transport protocol 
processing required to transfer the content is performed 
and a basic transport header is generated (S407), a 
packet being sent which includes the basic transport 
header, the encryption expansion header, and the en- 
crypted content (S409). 
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Description 

BACKGROUND OF THE INVENTION 

1 . Field of the Invention 

[0001] The present invention relates to a content dis- 
tribution apparatus, a content receiving apparatus, and 
a content distribution method. More particularly, it re- 
lates to technology in real-time distribution of content 
via an open network such as the Internet, whereby pro- 
tection is provided against content theft by third parties 
and unauthorized copying of content by a content recip- 
ient, thereby enabling transmission and reception of 
content data while considering copyright protection. 

2. Description of the Related Art 

[0002] In recent years, the digitization of the home 
sound and image (audio/visual; hereinafter abbreviated 
AV) environment, as exemplified by the start of digital 
broadcasts and the sales of digital AV equipment has 
gained much attention. Digital AV data enables diverse 
types ot compression, is amenable to processing as 
multimedia data, tolerates unlimited playback without 
deterioration, and has other features which are expect- 
ed to result in an expansion in its application in the fu- 
ture 

[0003] On the other hand, digital AV data technology 
is accompanied by the problem of easy unauthorized 
copying of content. More specifically, any type of digital 
content can in principle be used to create a copy iden- 
tical to the original and indefinitely durable, by means of 
bit copying, in the process of unauthorized content cop- 
ying. 

[0004] A variety of technologies are being studied for 
the purpose of preventing unauthorized copying. One of 
these is the 1 394CP Content Protection System Spec- 
ification being studied by the CPTWG (Content Protec- 
tion Technical Working Group). In this technology, an au- 
thentication procedure is performed beforehand be- 
tween sending and receiving nodes for content (such as 
MPEG data) to be transferred between nodes connect- 
ed by the IEEE 1394 bus, to enable shared use of an 
encryption key (content key). Thereafter, this encryption 
key is used to encrypt the content and then encrypted 
content is transferred, and it is not possible for nodes 
other than the nodes that performed the authentication 
procedure to decrypt the content. By doing this, because 
a node other than the authenticated nodes (that is, a 
third party node) does not know the encryption key, even 
the node were able to capture the transferred data (that 
is, the encrypted content data), it would not be able to 
decrypt it. Nodes that can participate in this authentica- 
tion procedure are limited to nodes that receive permis- 
sion to do so by an authentication organization before- 
hand, thereby preventing an unauthorized node from 
obtaining the encryption key, and thus preventing unau- 



thorized copying of content. 

[0005] The distribution of digital content is not, of 
course, limited to transfer via the IEEE 1394 bus, and 
general networks are expected to be used. The Internet 
5 is a strong candidate for building a technology infra- 
structure that is not wedded to public networks or phys- 
ical/link networks. 

[0006] In conventional content distribution as prac- 
ticed, however, digital content on the Internet (and in 
10 particular digital AV streams ) was mainly transferred in 
its raw form by the RTP (Real-time Transport Protocol), 
without copyright protection provided by prevention of 
third-party theft and unauthorized copying by a recipi- 
ent. 

SUMMARY OF THE INVENTION 

[0007] Accordingly, it is an object of the present inven- 
tion, in consideration of the above-noted situation, to 

20 provide content distribution apparatus, a content receiv- 
ing apparatus, and a content distribution method, which 
provide protection from copying when digital content is 
transferred on the Internet by real-time streaming. 
[0008] A feature of the present invention is that infor- 
ms mation with regard to encryption and encoding etc. re- 
quired to provide copy protection for digital content is 
efficiently appended as various headers to the content, 
making use of the characteristics of the Internet. 
[0009] One aspect of the present invention provides 

30 a content information distribution apparatus for distrib- 
uting encrypted content information, via a network in ac- 
cordance with a prescribed transport protocol, to other 
end apparatus in a communication authenticated by an 
authentication process including at least one procedure 

35 of an authentication procedure and a key exchange pro- 
cedure, comprising: (a) a unit for encrypting content in- 
formation encoded by a prescribed encoding system; 
(b) a unit for generating an encryption attribute header 
including attribute information with regard to the encryp- 

40 tion of the content information; (c) a unit for performing 
transport protocol processing required to transfer the 
content information and for generating a basic transport 
header to be added to the content information to which 
the encryption attribute header has been added; and (d) 

45 a unit for sending to the other end apparatus that is au- 
thenticated a packet including the basic transport head- 
er, the encryption attribute header, and the encrypted 
content information, wherein the encryption attribute 
header is set into an expansion transport header within 

50 a packet header of the packet or into a payload header 
within a payload to be encrypted of the packet. 
[0010] It is preferable that the encryption attribute 
header includes at least one of the existence or non- 
existence of encryption of the content information and 

55 the encryption system of the content information. 

[0011] It is preferable that the encryption attribute 
header includes a copy attribute field having a plurality 
of bits with regard to the number of copying of the con- 
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tent information. 

[0012] ft is preferable that the encryption attribute 
header includes a counter field indicating a change in 
an encryption key. 

[001 3] It is preferable that the unit (b) sets the encod- 
ing information, which indicates the encoding system for 
the content information into the expansion transport 
header or into the payload header. 
[0014] It is preferable that the unit (c) further codes 
into the basic transport header at least information to 
the effect that there is a possibility that the content in- 
formation is encrypted, and wherein the unit (b) codes 
into the expansion header at least information as to 
whether or not the content information to be transferred 
is encrypted. 

[0015] It is preferable that the unit (b) codes into the 
expansion header information as to whether or not the 
content information to be transferred is encrypted. 
[0016] The above-noted content information distribu- 
tion apparatus can further comprising: (e) a unit for gen- 
erating a content attribute header that includes content 
attribute information with regard to content information, 
and for setting this content attribute header into the ex- 
pansion transport header or into the payload header. 
[0017] The content attribute header need not be en- 
crypted. 

[0018] The unit (a) generates the encryption key 
based on an identifier that uniquely identifies a storage 
medium sent from the other end apparatus in the com- 
munication 

[0019] Another aspect of the present invention pro- 
vides a content information receiving apparatus authen- 
ticated by an authentication process including at least 
one procedure of an authentication procedure and a key 
exchange procedure and which receives encrypted con- 
tent information via a network in accordance with a pre- 
scribed transport protocol, comprising: (aa) a unit for re- 
ceiving from a sending apparatus a packet containing a 
basic transport header, an encryption attribute header 
including attribute information with regard to the encryp- 
tion of the content information, and encrypted content 
information; (bb) a unit for referring to the basic transport 
header or encryption attribute header and judging 
whether or not the content information is encrypted or 
whether there is a possibility that the content information 
is encrypted; and (cc) a unit that, when a judgment is 
made by the unit (bb) that the content information is en- 
crypted, decrypts the encrypted conlenl information, 
based on the attribute information with regard to encryp- 
tion included in the encryption attribute header. 
[0020] It is preferable that the unit (bb), when there is 
a possibility that the content information is encrypted, 
refers to the encryption attribute header and judges 
whether or not the content information is encrypted. 
[0021] It is preferable that the unit (bb) refers to the 
basic transport header or to the encryption attribute 
header to make a judgment as to the encoding system 
of the content information. 



[0022] The above-noted apparatus can further com- 
prising: (dd) a unit for referring to a received basic trans- 
port header and, when a prescribed delay time has 
elapsed or a prescribed number of packets have been 
s discarded, requesting that the sending apparatus send 
a prescribed encryption parameter. 
[0023] Another aspect of the present invention pro- 
vides a method of distributing encrypted content infor- 
mation, via a network in accordance with a prescribed 
io transport protocol, to other end apparatus in a commu- 
nication authenticated by an authentication process in- 
cluding at least one procedure of an authentication pro- 
cedure and a key exchange procedure, comprising the 
steps of: (a) encrypting content information encoded by 
is a prescribed encoding system: (b) adding an encryption 
attribute header including attribute information with re- 
gard to the encryption of the content information to the 
encrypted content information; (c) adding a content at- 
tribute header indicating attributes of the content infor- 
mation to content information to which the encryption 
attribute header has been added; (d) performing trans- 
port protocol processing required to transfer the content 
information , and adding a basic transport header to con- 
tent information to which the content attribute header 
has been added; and (e) sending a packet including the 
basic transport header, the encryption attribute header, 
the content attribute header, and the encrypted content 
information to the other end authenticated apparatus, 
wherein the encryption attribute header is set into either 
an expansion transport header within a packet header 
of the packet, or into a payload header within an encrypt- 
ed payload of the packet. 

[0024] Another aspect of the present invention pro- 
vides a method of distributing encrypted content infor- 
mation, via a network in accordance with a prescribed 
transport protocol, to other end apparatus in the com- 
munication authenticated by an authentication process 
including at least one procedure of an authentication 
procedure and a key exchange procedure, comprising 
the steps of: (a 1 ) adding a content attribute header indi- 
cating attributes of the content information to the content 
information to be transferred; (b 1 ) encrypting content in- 
formation that are encoded by a prescribed encoding 
system and to which the content attribute header has 
been added; (c') adding to the encrypted content infor- 
mation an encryption attribute header including attribu- 
tion information with regard to the encryption of the con- 
tent information; (d') performing transport protocol 
processing required to transfer the content information, 
and adding a basic transport header to content informa- 
tion to which the encryption attribute header has been 
added; and (e') sending a packet including the basic 
transport header, the encryption attribute header, the 
content attribute header, and the encrypted content in- 
formation to the other end authenticated apparatus, 
wherein the encryption attribute header is set into either 
an expansion transport header within a packet header 
of the packet, or into a payload header within a payload 
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to be encrypted of the packet. 

[0025] Another aspect of the present invention pro- 
vides a method of receiving encrypted content informa- 
tion, via a network in accordance with a prescribed 
transport protocol, by an authentication process includ- s 
ing at least one procedure of an authentication proce- 
dure and a key exchange procedure, comprising the 
steps of: (aa) receiving a packet including a basic trans- 
port header, an encryption attribute header including en- 
cryption attribute information with regard to the encryp- 10 
tion of the content information, and encrypted content 
information; (bb) referring to the basic transport header 
and judging whether or not the content information is 
encrypted or whether or not there is a possibility that the 
content information is encrypted; (cc) referring to the en- is 
cryption attribute header and extracting encryption at- 
tribute information with regard to encryption of the con- 
tent information; (dd) relerringtoan expansion transport 
header within a packet header of the packet and extract- 
ing content attribute information with regard to the con- 20 
tent information; and (ee) in the case in which a judg- 
ment is made at (bb) that the content information is en- 
crypted, decrypting the encrypted content information, 
based on the extracted encryption attribute information. 
[0026] Another aspect of the present invention pro- 25 
vides a method of receiving encrypted content informa- 
tion, via a network in accordance with a prescribed 
transport protocol, by a authentication process including 
at least one procedure of an authentication procedure 
and a key exchange procedure, comprising the steps 30 
of: (aa') receiving a packet including a basic transport 
header, an encryption attribute header including encryp- 
tion attribute information with regard to the encryption 
of the content information, and encrypted content infor- 
mation; (bb ) referring to the basic transport header and 35 
judging whether or not the content information is en- 
crypted or whether or not there is a possibility that the 
content information is encrypted; (cc 1 ) in the case in 
which a judgment is made at (bb 1 ) that the content infor- 
mation is encrypted, referring to the encryption attribute 40 
header and extracting encryption attribute information 
with regard to the encryption of the content information; 
(dd') in the case in which a judgment is made at (bb 1 ) 
that the content information is encrypted, decrypting the 
encrypted content information based on the extracted 45 
encryption attribute information; and (ee') referring to an 
expansion transport header within a packet header of 
the packet and extracting content attribute information 
with regard to the content information. 

[0027] Another aspect of the present invention pro- 50 
vides a computer-readable recording medium for re- 
cording a program to be executed by a computer, the 
program performing distribution of encrypted content in- 
formation, via a network in accordance with a prescribed 
transport protocol, to other end apparatus in a commu- ss 
nication authenticated by an authentication process in- 
cluding at least one procedure of an authentication pro- 
cedure and a key exchange procedure, the program 



comprising: (a) a module for generating an encryption 
attribute header including attribute information with re- 
gard to encryption of the content information: (b) a mod- 
ule for performing transport protocol processing re- 
quired to transfer the content information and for gener- 
ating a basic transport header to be added to the content 
information to which the encryption attribute header has 
been added; and (c) a module for sending a packet in- 
cluding the basic transport header the encryption at- 
tribute header, and the encrypted content information to 
the other end authenticated apparatus, wherein the en- 
cryption attribute header is set either into an expansion 
transport header within a packet header of the packet 
or into a payload header within a payload to be encrypt- 
ed of the packet 

[0028] Another aspect of the present invention pro- 
vides a computer-readable recording medium for re- 
cording a program to be executed by a computer, the 
program performing receiving of encrypted content in- 
formation, via a network in accordance with a prescribed 
transport protocol, by an authentication process includ- 
ing at least one procedure of an authentication proce- 
dure and a key exchange procedure, the program com- 
prising: (aa) a module for receiving from a sending ap- 
paratus a packet including a basic transport header, an 
encryption attribute header including attribute informa- 
tion with regard to encryption of the content information, 
and encrypted content information; (bb) referring to the 
basic transport header or the encryption attribute head- 
er and judging whether or not the content information is 
encrypted or whether there is a possibility that the con- 
tent information is encrypted: and (cc) in the case in 
which a judgment is made by module (bb) that the con- 
tent information is encrypted, decrypting the encrypted 
content information based on attribute information with 
regard to encryption included in the encryption attribute 
header. 

[0029] Other features and advantages of the present 
invention will become apparent from the following de- 
scription taken in conjunction with the accompanying 
drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0030] The accompanying drawings, which are incor- 
porated in and constitute a pan of the specification, il- 
lustrate presently preferred embodiments of the inven- 
tion, and together with the general description given 
above and the detailed description of the preferred em- 
bodiments given below, serve to explain the principles 
of the invention, wherein: 

Fig. 1 is a drawing showing an example of a config- 
uration of a network associated with the first em- 
bodiment to the sixth embodiment of the present in- 
vention; 

Fig. 2 is a diagram showing an example of a se- 
quence of content distribution in the first embodi- 
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ment to the sixth embodiment of the present inven- 
tion; 

Fig. 3 is a block diagram showing an example of the 
configuration of an MPEG distribution server ac- 
cording to the first embodiment of the present in- 
vention; 

Fig. 4 is a flowchart showing the procedure for con- 
tent distribution processing in an MPEG distribution 
server according to the first embodiment of the 
present invention, 

Fig. 5 is a drawing showing a first example of a for- 
mat of a code expansion header; 
Fig. 6 is a drawing showing a first example of the 
format of a header given by an RTP processor; 
Fig. 7 is a drawing showing a first example of a for- 
mat of a transferred IP packet; 
Fig. 8 is a block diagram showing an example of the 
configuration of a receiving apparatus according to 
the first embodiment of the present invention; 
Fig. 9 is a flowchart showing the procedure for con- 
tent receiving processing in a receiving apparatus 
according to the first embodiment of the present in- 
vention; 

Fig. 10 is a block diagram showing an example of 
the configuration of an MPEG distribution server ac- 
cording to the second, third, or fifth embodiment of 
the present invention; 

Fig. 11 is a drawing showing a second example of 
a format of a header given by an RTP processor; 
Fig. 12 is a drawing showing the second example 
of the format of a transferred IP packet; 
Fig. 1 3 is a flowchart showing the p rocedure for con- 
tent distribution processing in an MPEG distribution 
server according to the second embodiment of the 
present invention; 

Fig. 14 is a block diagram showing an example of 
the configuration of a receiving apparatus accord- 
ing to the second, third, or fifth embodiment of the 
present invention; 

Fig. 1 5 is a flowchart showing the procedure for con- 
tent receiving processing in a receiving apparatus 
according to the second embodiment of the present 
invention; 

Fig. 16 is a drawing showing a third example of a 
format of a header given by an RTP processor; 
Fig. 17 is a drawing showing a third example of a 
format of a transferred IP packet; 
Fig. 18 is a block diagram showing an example of 
the configuration of an MPEG distribution server ac- 
cording to the fourth or sixth embodiment of the 
present invention; 

Fig. 19 is a drawing showing a fourth example of a 
format of a header given by an RTP processor; 
Fig. 20 is a drawing showing a fourth example of a 
format of a transferred IP packet; 
Fig. 21 is a flowchart showing a procedure for con- 
tent distribution processing in an MPEG distribution 
server according to the fourth embodiment of the 
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present invention; 

Fig. 22 is a block diagram showing an example of 
the configuration of a receiving apparatus accord- 
ing to the fourth or sixth embodiment of the present 
invention: 

Fig. 23 is a flowchart showing a procedure for con- 
tent receiving processing in a receiving apparatus 
according to the fourth embodiment of the present 
invention; 

Fig. 24 is a drawing showing a fifth example of a 
format of a header given by an RTP processor; 
Fig. 25 is a drawing showing a second example of 
a format of a code expansion header; 
Fig. 26 is a drawing showing a fifth example of a 
format of a transferred IP packet; 
Fig. 27 is a drawing showing a sixth example of a 
format of a header given by an RTP processor; 
Fig. 28 is a drawing showing a sixth example of a 
format of a transferred IP packet; 
Fig. 29 is a drawing showing an example of the con- 
figuration of a network according to the seventh em- 
bodiment of the present invention; 
Fig. 30 is a drawing showing an example of the se- 
quence of content distribution according to the sev- 
enth embodiment of the present invention; 
Fig. 31 is a block diagram showing an example of 
the configuration of an MPEG distribution server ac- 
cording to the seventh embodiment of the present 
invention; 

Fig. 32 is a drawing showing a seventh example of 
a format of a transferred IP packet; 
Fig. 33 is a drawing showing a seventh example of 
a format of a header given by an RPT processor; 
Fig. 34 is a block diagram showing an example of 
the configuration of a receiving apparatus accord- 
ing to the seventh embodiment of the present inven- 
tion; and 

Fig. 35 is a drawing showing an example of the se- 
quence of content distribution according to the 
eighth embodiment of the present invention. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

[0031] Embodiments of a content distribution appara- 
tus, a content receiving apparatus, and a content distri- 
bution method according to the present invention are 
described in detail below, with reference to Fig. 1 
through Fig. 35. 

First Embodiment 

[0032] The first embodiment of a content distribution 
apparatus : a content receiving apparatus, and a content 
distribution method according to the present invention 
is described in detail below, with reference to Fig. 1 
through Fig. 9. 

[0033] Fig. 1 shows an example of the configuration 
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of a content distribution system according to this em- 
bodiment of the present invention. In Fig. 1, an MPEG4 
distribution server 101 and a receiving apparatus 102 
according to this embodiment are connected to the In- 
ternet 103, MPEG4AV stream data being securely com- 
municated between the MPEG4 distribution server 101 
and the receiving apparatus 102, via the Internet 103. 
Of course, other MPEG4 distribution servers and receiv- 
ing apparatuses and other types of equipment can ad- 
ditionally be connected to the Internet 103. 
[0034] In the description of embodiments to follow 
while the type of data is MPEG (Motion Picture Experts 
Group) 4, it will be understood that the present invention 
is not restricted to application to this type of data, and 
can be applied to other data types as well. 
[0035] The MPEG4 distribution server 101 performs 
distribution of MPEG4 data to the receiving apparatus 
102. MPEG4 data is distributed not in the form of file 
transfer, but rather as data stream. The MPEG4 data 
that is to be copyright protected is distributed in encrypt- 
ed form. When doing this, an authentication procedure 
or key exchange procedure is performed between the 
MPEG4 distribution server 101 and the receiving appa- 
ratus 102. 

[0036] The sequence of this procedure is illustrated 
by example in Fig. 2. 

[0037] Fig. 2 shows the sequence of content layer en- 
cryption and authentication, and it should be noted that 
security in layers such as the IP layer and transport layer 
and authentication procedures in those layers have 
been omitted from this drawing, as has the procedure 
for assessing charges at the content layer, which is per- 
formed earlier (although there are cases in which charge 
assessment and authentication/encryption at other lay- 
ers are not performed). 

[0038] Consider the case in which the receiving ap- 
paratus 1 02 makes a request to the MPEG4 distribution 
server 101 for distribution. In this case, the first authen- 
tication request is sent from the receiving apparatus 1 02 
(S201 ). In this authentication request, there can also be 
a simultaneous exchange of a certificate (equipment 
certification) that is received by the apparatus (receiving 
apparatus 102) from a certification organization, the cer- 
tificate certifying that the equipment is capable of per- 
forming transfer of copyright protected content. 
[0039] The "equipment ID" that is used in the equip- 
ment certification can be an IP address, and in the case 
in which the IP address is given by a DHCP (Dynamic 
Host Configuration Protocol) server, there is a possibility 
that this value will differ each time the apparatus is boot- 
ed. Because of this situation, it is possible to use as the 
"equipment ID" for equipment certification the MAC ad- 
dress of the equipment, or the EU164 address, or an ad- 
dress created by adding to these address a partial mod- 
ule number. It is further possible to use as the "equip- 
ment ID" the CPU ID number of the apparatus, or the 
MPEG4 decoder ID number or the like, which (ideally) 
is a value that is unique worldwide (or that can be ex- 



pected to be unique or almost unique within the region). 
[0040] An MPEG4 distribution server 101 that re- 
ceives a message from the receiving apparatus 101, 
performs a response to the authentication request and 
5 performs exchange of a certificate (equipment certifica- 
tion) (S202). 

[0041] Next, the MPEG4 distribution server 101 and 
the receiving apparatus 1 02 perform a process that gen- 
erates an authentication key, for the purpose of gener- 
ic ating a common authentication key (S203). Details of 
this procedure can be the same as, for example, the 
IEEE 1394 copy protection key generation process. 
When this process is completed, the MPEG4 distribu- 
tion server 101 and the receiving apparatus 102 can 
is possess a common authentication key Kauth, which is 
not knowable to a third party: 

[0042] Next, the MPEG4 distribution server 101 
sends G(Kx, Kauth) which is generated by certain func- 
tion G with the use of an exchange key Kx, the authen- 
20 tication key Kauth as arguments, and a random number 
Nc to the receiving apparatus 102 (S204, S205). At the 
receiving apparatus 102, reverse function of G(Kx, 
Kauth) is calculated so as to extract the exchange key 
Kx. 

25 [0043] At this point in time, the MPEG4 distribution 
server 101 and the receiving apparatus 102 share the 
three values of authentication key Kauth, exchange key 
Kx, and the random number Nc. 

[0044] At this point, the encryption key (content key) 

30 Kc, which is the encryption key for encrypting the 
MPEG4 data to be sent by the MPEG4 distribution serv- 
er 101 and for the receiving apparatus 102 to decrypt 
the received encrypted MPEG4data (that is the shared 
key), is calculated in the MPEG4 distribution server 101 

35 and the receiving apparatus 1 02, respectively, by using 
one and the same pre-established function J, as a func- 
tion of part of the above-noted value. For example, the 
calculation is made as Kc=J[Kx, f(EMI), Nc], in which 
EMI indicates the copy attribute for the data (content), 

40 which expresses such attributes as the data being co- 
piable without limit, the data being copiable only 1 time, 
the data being copiable only 2 times, the data being un- 
copiabte under any conditions, or the data being already 
copied and therefore not further copiable. f(EMI) is ob- 

45 tained by transforming the attribute value of EMI with 
the use of certain specific function f . These functions J 
and f can also be kept maintained as secret with respect 
to the outside. 

[0045] After the encryption key (content key) Kc is 
so generated, the MPEG4 distribution server 101 encrypts 
the content (MPEG4 data) using the encryption key Kc, 
and sends the encrypted content to the Internet (S206, 

S207, ...). 

[0046] As will be described below, because the en- 
55 crypted content is in the form of AV stream data trans- 
ferred in real time over the Internet, in the first embodi- 
ment of the present invention RTP (Real-time Transport 
Protocol) is used as the transport protocol. 
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[0047] It is also possible to make the encryption key 
Kc vary with time (that is, have its value change with the 
passage of time). 

[0048] For example, if the elapse of a prescribed 
amount of time (which can be a fixed amount of time, or 5 
a variable amount of time) from the previous change is 
recognized, the value of the variable Nc is incremented, 
and the above-noted function J is used to calculate the 
encryption key Kc. When this is done, the timing of up- 
dating of the encryption key Kc value (or the data at the 10 
point at which the encryption key Kc is to be updated) 
must be recognized synchronously at the sending and 
receiving sides. For this reason, regions such as Even/ 
Odd field is provided in the transferred MPEG4 data (AV 
data), and the point at which there is a change in the is 
field is established as the point at which the value of the 
variable Nc, that is, the value of the encryption key Kc 
is changed, so that data after the field change point is 
encrypted with the updated encryption key Kc. 
[0049] The MPEG4 distribution server 101 monitors 20 
the above-noted elapse of time and, when the timing for 
the updating of the encryption key Kc is detected, the 
value of the variable Nc is incremented and the encryp- 
tion key Kc is calculated again, the recalculated value 
of the encryption key Kc being used to encrypt the 2S 
MPEG4 data that is to be sent, the Even/Odd field value 
being incremented, and transmission being performed. 
Thereafter, until the timing for the next updating, this up- 
dated encryption key Kc is used to perform encryption. 
[0050] At the receiving apparatus 102, the received 30 
Even/Odd field value is monitored, comparing the value 
with the immediately previously received value and, if 
the value is detected as being different from the imme- 
diately previously received value, the value of the vari- 
able Nc is incremented, and the value of encryption key 35 
Kc is recalculated, the encryption key Kc after this re- 
calculation being used in decrypting received encrypted 
data. Thereafter, until the next change in the Even/Odd 
field value is detected, this value of encryption key Kc 
is used to perform decryption. 40 
[0051] In this manner, encrypted MPEG4 data is 
transferred between the MPEG4 distribution server 101 
and the receiving apparatus 102. 
[0052] Fig. 3 shows an example of the internal con- 
figuration of the MPEG4 distribution server 101 . 45 
[0053] As shown in Fig. 3, the MPEG4 distribution 
server 101 of this embodiment comprises a MPEG data 
generator 301 , a data encryplor 302, an RTP processor 

303, an RTCP transmitter 307, a TCP/IP and UDP/IP 
processor 306, a link/physical layer processor 309, an so 
RCTP receiver/interpreter 310, and an authentication/ 
key exchange processor 311. The RTP processor 303 
includes an encryption expansion header adding unit 

304, an MPEG4 expansion header adding unit 305, and 

an RTP basic header adding unit 306, and performs 55 
processing related to the RTP 

[0054] Next, the procedure for processing the content 
distribution in the MPEG4 distribution server 101 ac- 



cording to the first embodiment is described below, with 
reference to Fig. 4. 

[0055] Processing related to authentication and en- 
cryption in the sequence of Fig. 2 (processing from S201 
to S205) and processing related to the above-described 
updating of the encryption key is performed by the au- 
thentication/key exchange processor 311 . This process- 
ing can be performed before or after the sending of con- 
tent to the receiving apparatus 102. 
[0056] The inputted AV information (for example, an 
analog signal) is compressed to MPEG4 data by the 
MPEG4 data generator 301 . 

[0057] When this is done, if MPEG attribute informa- 
tion such as the location of I pictures (intra-coded pic- 
tures) and the encoding rate are sent simultaneously 
with the MPEG4 data to notify the receiving side, play- 
back (decoding) at the receiving side is facilitated. In 
particular on the Internet, where such things as discard- 
ed and delayed packets and a change in the sequence 
of arrival of packets can occur, this attribute information 
is essential to achieve high-quality playback at the re- 
ceiving side. For example, in the case of MPEG4 in the 
first embodiment, information about, for example, the 
VOP header corresponds to these attributes. Cases can 
be envisioned in which information with regard to the 
MPEG4 system, for example transmission of synchro- 
nization information at a sync layer, information for mul- 
tiplexing when sending a plurality of MPEG4 streams in 
multiplexed format, or information with regard to initial 
and latest values of object descriptors is required For 
this reason, when sending AV data by RTP, the above- 
noted information is coded into the RTP expansion 
header or into the payload header of the RTP payload 
(that is, user area), so that the MPEG attribute informa- 
tion is sent along with the AV data. 
[0058] In the first embodiment, this MPEG attribute in- 
formation is sent in the form of an RTP expansion head- 
er. That is, it is sent as an RTP expansion header of the 
ID type of MPEG4 expansion header. For this reason, 
required information with regard to encoding is sent from 
the MPEG4 data generator 301 as notification to the 
MPEG4 expansion header adding unit 305. 
[0059] Next, the MPEG4 data outputted from the 
MPEG4 data generator 301 is encrypted by the data en- 
cryptor 302 (step S401 in Fig. 4). When this is done, the 
encryption key may be the above-noted time-variant en- 
cryption key Kc. With regard to the encryption process- 
ing as well, a variety of attribute information can be en- 
visioned. In the first embodiment, an RTP expansion 
header whose ID type indicates the encryption expan- 
sion header is added by the encryption expansion head- 
er adding unit 304 (step S403). For this reason, infor- 
mation required for the generation of an encryption ex- 
pansion header is sent as notification from the data en- 
crypter 302 to the encryption expansion header adding 
unit 304. 

[0060] In order to perform the above-noted encryption 
processing, at the authentication/key exchange proces- 
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sor 31 1 when the timing for updating the encryption key 
Kc is reached, Nc is incremented and the above-de- 
scribed function J is used to generate a new encryption 
key Kc which is passed to the data encrypter 302. Along 
with this, the value of Even/Odd field is incremented and s 
passed to the data encrypter 302. The value Even/Odd 
field is passed, as noted above, from the data encrypter 
302 to the encryption expansion header adding unit 304. 
[0061] Fig. 5 shows an example of an encryption ex- 
pansion header. The encryption expansion header has 
a expansion header type field, a encryption on/off field, 
encryption type indication field, an encryption mode in- 
dicator (EMI) field, and an Even/Odd field. 
[0062] The expansion header type field is for coding 
information that indicates the type of corresponding ex- 
pansion header. In this case, information that indicates 
the encryption expansion header is coded into the ex- 
pansion header type field. 

[0063] The encryption on/off field is a field for coding 
information indicating whether or not the data trans- 
ferred in the corresponding RTP packet is encrypted. 
[0064] The encryption type indicator field is a field for 
coding the type of encryption used with respect to data 
transferred in an RTP packet. For example, in Fig. 5, 
information is described that indicates "an M6 encryp- 
tion type". 

[0065] The encryption mode indicator (EMI) field is a 
field for coding the above-noted copy attribute value 
EMI. 

[0066] The Even/Odd field, as noted above, is a field 
for notifying the receiving side from the sending side of 
the timing of updating of the encryption key. 
[0067] Although in the example shown each field has 
8 bits, there is no restriction to the number of bits, and 
the number of bits can be appropriately established as 
desired. 

[0068] When AV data is encrypted and sent to the re- 
ceiving side, if it is desired to perform such trick play as 
fast-forwarding, or sending of partial static images, there 
are cases in which processing at the receiving side be- 
comes difficult. This is because it is difficult to perform 
a task such as sending just a part of an encrypted AV 
data stream (for example, because the Nc value would 
not be incremented but would rather skip over a number 
of values). For this reason, in certain cases it is desirable 
to send AV data to the receiving side without encrypting 
it. In such cases, it is necessary to notify the receiving 
side by information as to whether or not the AV data has 
been encrypted. The above-noted encryption on/off field 
is provided for such purposes. 

[0069] Additionally, on the Internet there is the possi- 
bility that one stream will use one encryption type and 
another stream use a different encryption type. In such 
cases, if there is a field that indicates to what type of 
encryption the AV data has been subjected, the receiv- 
ing side can examine this field so as to select a proper 
decryption engine for describing the data. The above- 
noted encryption type indicator field is provided for this 



type of purpose. 

[0070] As shown in Fig. 5, the encryption mode indi- 
cator (EMI) field is 8 bits rather than the 2 bits that are 
used in the case of IEEE 1 394. This is in order to estab- 
lish the freedom to select a value of N used to give no- 
tification of the specification of the number of copies N 
of the AV data that are to be permitted, and for cases in 
which a special type of copying (for example, permitting 
copying only when some condition is satisfied), in which 
case this field must be able to take a larger number of 
values than would be possible with 2 bits. 
[0071] As shown in Fig. 5. in the Even/Odd field, in 
contrast to the 1 bit used in IEEE 1394, there are 8 bits 
provided. This is because 1 bit would not allow enough 
information for the Internet, in which as noted above it 
is possible to have discarded or delayed packets and 
an altered sequence ol packet arrivals. Thus, for exam- 
ple, on the Internet a case can be envisioned in which, 
with the Even/Odd bit 1 as shown at step S207, all the 
packets are discarded. In this case, if the Even/Odd field 
were to be just 1 bit, the Even/Odd field would return to 
0 at the next packet, so that as seen from the receiving 
side the condition in which the Even/Odd bit is 0 is con- 
tinuing (that is, not changing) Thus, although Nc should 
actually be incremented by 2, if the Even/Odd bit value 
is not changed, the Nc value is not incremented, thereby 
preventing generation of the correct encryption key. Be- 
cause of this situation, more than 2 bits, for example 8 
bits, are provided in the Even/Odd field, so that even if 
packet discarding and delay, or resequencing of packet 
arrival occurs, as it can on the Internet, it is possible to 
perform appropriate processing on the receiving side. 
[0072] In the first embodiment of the present inven- 
tion, data encryption is performed only with respect to 
MPEG4 data itself, and not with respect to the MPEG4 
expansion header. Because the MPEG4 expansion 
header is not content that need to be copyright protect- 
ed, but is rather used on the receiving side before the 
MPEG4 data itself is used, enabling it to omitted from 
the data that is encrypted. 

[0073] In the RTP processor 303, an encryption ex- 
pansion header is added to the MPEG4 data by the en- 
cryption expansion header adding unit 304, an MPEG4 
expansion header is added to the MPEG4 data by the 
MPEG4 expansion header adding unit 305 (step S405 
in Fig. 4), and an RTP basic header is added to the 
MPEG4 data by the RTP basic header adding unit 306 
(step S407), the ultimate result being the addition of the 
RTP header such as shown in Fig. 6. The encryption 
expansion header is generated based on information 
from the data encrypter 302, and the MPEG4 expansion 
header is generated based on information from the 
MPEG4 data generator 301. The RTP header has ele- 
ments that are basic parameters required for AV data 
transfer via the Internet, such as a time stamp and a 
sequence number (for details, refer to RFC 1889). 
[0074] Encrypted MPEG4 data to which the RTP 
header has been added is sent to the Internet 103 by 
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the TCP/IP and-UDP/IP processor 308 as an IP packet 
as shown in Fig. 7, via the link/physical layer processor 
309. 

[0075] Next, the configuration of the receiving appa- 
ratus 102 and the procedure for processing therein will 
be described. 

[0076] Fig. 8 shows the internal configuration of the 
receiving apparatus 102. 

[0077] As shown in Fig 8, the receiving apparatus 
102 according to the first embodiment comprises a link/ 
physical layer processor 701, a TCP/IP and UDP/IP 
processor 702, an RTP processor 703, a data encryptor/ 
decryptor 707, anMPEG4 data decoder 708, a receiving 
condition interpreter 709, an RTCP transmitter 710, and 
an authentication/key exchange processor 711. The 
RTP processor 703 includes an RTP basic header re- 
ceiver/interpreter 704, an MPEG4 expansion header re- 
ceiver/interpreter 705, and an encryption expansion 
header receiver/interpreter 706, and performs process- 
ing related to the RTP 

[0078] Fig. 9 shows a procedure for encrypted content 
receiving processing performed by the receiving appa- 
ratus 102 of the first embodiment of the present inven- 
tion. 

[0079] Processing related to authentication and en- 
cryption of the sequence of Fig. 2 (processing from S20 1 
to S205) and processing related to encryption key up- 
dating is performed by the authentication/key exchange 
processor 711. 

[0080] The receiving apparatus 102 basically per- 
forms processing in a sequence that is the reverse of 
the processing performed by the MPEG4 distribution 
server 101. 

[0081] Specifically, MPEG4data (encrypted data with 
an added RTP header) transferred via the Internet 103 
passes through the link/physical layer processor 701 to 
the TCP/IP and UDP/IP processor 702 and is then in- 
putted to the RTP processor 703 (step S901 in Fig. 9). 
[0082] At the RTP processor 703, the RTP basic 
header is interpreted by the RTP basic header receiver/ 
interpreter 704 (step S903 in Fig. 9), the MPEG4 expan- 
sion header is interpreted by the MPEG4 expansion 
header receiver/interpreter 705 (Step S905), and the 
encryption expansion header is interpreted by the en- 
cryption expansion header receiver/interpreter 706 
(Step S907). Information required for decoding is sent 
as notification from the MPEG4 expansion header re- 
ceiver/interpreter 705 to the MPEG4 data decoder 706, 
and information required for decryption is sent from the 
encryption expansion header receiver/interpreter 706 to 
the data encyptor/decryptor 707. 

[0083] The encrypted data stored in the RTP payload 
is passed from the RTP processor 703 to the data en- 
cryptor/decryptor 707. The data encryptor/decryptor 
707 performs decryption of data : based on information 
from the encryption expansion header receiver/inter- 
preter 706. 

[0084] The encryption key used in decryption is the 



above-described time-variant encryption key Kc. That 
is, the data encryptor/decryptor 707 refers to a value of 
the encryption on/off field of the encryption expansion 
header sent as notification from the encryption expan- 
5 sion receiver/interpreter 706, so as to learn that the re- 
ceived data is encrypted (as a result of which the de- 
cryption thereof is determined), after which the Even/ 
Odd field is referenced and a comparison is made be- 
tween the value thereof and a previously received value. 

10 if the value had been an increment, it is known that the 
encryption key is to be updated (but if the values are the 
same, the encryption key will not be updated). Then, the 
fact that the encryption key is to be updated is notified 
to the authentication/key exchange processor 711 from 

is the data encryptor/decryptor 707, and in the authentica- 
tion/key exchange processor 711 since the timing for up- 
dating the encryption key Kc has been reached, Nc is 
incremented and the above-noted function J is used to 
generate a new encryption key Kc, which is passed to 

20 the data encryptor/decryptor 707. 

[0085] Decrypted MPEG4 data is passed from the da- 
ta encryptor/decryptor 707 to the MPEG4 data decoder 
708. The MPEG4 data decoder 708 decodes this 
MPEG4 data, based on information from the MPEG4 ex- 

2S pansion header receiver/interpreter 705, and outputs 
the results as an AV output data (for example, an analog 
signal). 

[0086] !n the above, the RTP has associated with it 
RTCP (Real-time Transport Control Protocol). RTCP 

30 monitors the RTP sequence number and time stamp 
and has the function of notifying the sending side (in the 
first embodiment, the MPEG4 distribution server 101) 
from the receiving side (in the first embodiment, the re- 
ceiving apparatus 1 02) with regard to the receiving con- 

35 dition (packet discarding rate, packet transmission de- 
lay time, and the like). This is performed by the receiving 
condition interpreter 709 and the RTCP transmitter 710. 
[0087] The MPEG4 distribution server 101 receives 
this RTCP packet at the RTCP receiver/interpreter 310 

40 and, if necessary, can apply feedback to the MPEG4 da- 
ta generator 301 , to attempt to achieve optimization. For 
example, in the case in which there is a great amount 
of packet discarding, network crowding can be envi- 
sioned, in response to which the bit rate of the MPEG4 

*s data generation can be lowered by feedback. 

[0088] The RTCP transmitter 307 of the MPEG4 dis- 
tribution server 101 transmits information required for 
RTCP 

[0089] On the other hand, as described above, in the 
so receiving apparatus 102 based on the results of moni- 
toring the Even/Odd field included in the encryption ex- 
pansion header of the received packet, the value of the 
variable Nc used in the calculation of the encrypt ion key 
Kc is changed. Therefore, if it is not possible for the 
ss sending side to reliably inform the receiving side that the 
value of Nc has been updated, the receiving side cannot 
calculate the encrypt ion key Kc, thereby making it im- 
possible to decrypt the arriving encrypted data. 
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[0090] Because the Internet is intrinsically a network 
on which discarding of packets can occur, it is not guar- 
anteed that the meaning of the Even/Odd field value 
(timing of incrementing) will be accurately informed to 
the other apparatus in a communication link (particularly 
in the case in which there are few bits in the Even/Odd 
field). Because of this situation, in the case in which the 
receiving apparatus 1 02 wishes to know the precise val- 
ue of Nc, it can be provided with the option to issue a 
request to the sending apparatus (in this embodiment, 
the MPEG4 distribution server 101) for the Nc value. 
[0091] As an example of a case in which the receiving 
apparatus 102 wishes to know the precise Nc value, 
consider the case in which there is more skipping than 
expected in the time stamp or the sequence number of 
the RTP basic header, in which case one solution envi- 
sionable is that of sending a packet to the sending side 
to request the value of Nc. This is because a skip greater 
than a pre-established limit could mean the possibility 
that the Even/Odd bit value has changed. This process- 
ing is performed by the authentication/key exchange 
processor 311 of the MPEG4 distribution server 101 or 
the authentication/key exchange processor 711 of the 
receiving apparatus 102. By doing this, even in the event 
that synchronization of tho Even/Odd bit is lost between 
the MPEG4 distribution server 1 01 and the receiving ap- 
paratus 1 02, it is possible to perform appropriate recov- 
ery processing. Furthermore, in the case in which there 
is notification of Nc value from the MPEG4 distribution 
server 101 to the receiving apparatus 102. it is possible 
to simultaneously send the time stamps and sequence 
numbers of the corresponding RTP, expansion header, 
or pay load header as notification. 
[0092] A case can be envisioned in which distributed 
data is accumulated in the receiving apparatus (or in 
some form of storage medium, such as DVD-RAM or 
the like, installed in the receiving apparatus), in which 
case the distributed data can be stored as is in the form 
of encrypted data, and the corresponding encryption 
key Kc stored together therewith. 

Second Embodiment 

[0093] Next, the second embodiment, in which there 
is a variation of the packet format in the first embodi- 
ment, is described below, with reference to Fig. 10 
through Fig. 15. Because the basic configuration and 
operation of the second embodiment is the same as that 
of the first embodiment, the description that follows fo- 
cuses on the differences introduced with the second em- 
bodiment compared to the first embodiment. 
[0094] The difference in the second embodiment with 
respect to the first is that, whereas in the first embodi- 
ment an encryption expansion header and MPEG4 ex- 
pansion header were added as expansion header in an 
RTP header (Fig. 6 and Fig. 7), in the second embodi- 
ment the encryption expansion header is added as the 
expansion header in the RTP header and the MPEG4 



expansion header is added as a payload header to the 
RTP payload (Fig. 11 and Fig. 12). 
[0095] The overall network configuration according to 
the second embodiment is similar to that of the first em- 
5 bodiment (Fig. 1 ). The processing sequence is also sim- 
ilar to that of the first embodiment (Fig. 2). The encryp- 
tion expansion header format is also similar to that of 
the first embodiment (Fig. 5). 

[0096] Fig. 10 shows an example of the configuration 
10 of an MPEG4 distribution server 101 according to the 
second embodiment. In this embodiment, because the 
MPEG4 expansion header is provided as a payload 
header for the RTP payload, the processing for applying 
the MPEG4 header is removed from the RTP process- 
es ing, so that the MPEG4 expansion header adding unit 
305 of Fig. 3 is removed from within the RTP processor 
305 and placed outside, this becoming the MPEG4 pay- 
load header adding unit 315, which is different than in 
the first embodiment. 
20 [0097] Fig. 11 shows the lormat of the RTP header 
used when sending encrypted AV data in the second 
embodiment. In the second embodiment, a payload type 
field that indicates an attribute of data that is transferred 
by an RTP packet (for example, encoding system) is 
25 provided in the RTP basic header. In the second em- 
bodiment, for example, if the transferred data is encrypt- 
ed MPEG4 data, this field will be coded with information 
indicating "the data is encrypted MPEG4 data". The re- 
ceiving apparatus 1 02 can know that transferred data is 
30 encrypted MPEG4 data with reference to this field 

[0098] Additionally in the second embodiment, the 
RTP basic header is provided with an X bit field that in- 
dicates whether or not there is an expansion header 
added to the RTP header In the second embodiment, 
35 the arrangement is that a bit indicating "the existence of 
an expansion header" is set. 

[0099] Fig. 1 2 shows the overall format of an I P packet 
transferred over the Internet by the second embodi- 
ment. 

40 [0100] Fig. 1 3 is a flowchart shows the procedure for 
processing of content distribution in the second embod- 
iment of the present invention. In this second embodi- 
ment, first the MPEG4 payload header adding unit 315 
adds an MPEG4 payload header to the content (step 

45 S400), the step S405 shown in Fig. 4 not being carried 
out. The processing of the other steps S401, S403, 
S407, and S409 is similar to the processing as de- 
scribed with regard to the first embodiment. However, 
the header has the above-noted information set into it. 

so [01 01] Next, the receiving apparatus 1 02 according to 
the second embodiment is described below. 
[0102] Fig. 14 shows an example of the configuration 
of the receiving apparatus 102 of the second embodi- 
ment. Similar to the above-noted MPEG4 distribution 

55 server 101, the processing of the MPEG4 expansion 
header is moved to outside of the RTP processor, the 
MPEG4 expansion header receiver/interpreter 705 of 
Fig. 8 being moved from inside the RTP processor 703 
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to outside, this becoming the MPEG4 payload header 
receiver/interpreter 715, which is different than in the 
first embodiment. 

[0103] Fig. 15 is a flowchart showing the procedure 
for receiving processing in a receiving apparatus 102 s 
according to the second embodiment. 
[0104] At the receiving apparatus 102, first a packet 
is received (step S901), and at the RTP basic header 
receiver/interpreter 704 it is learned that the received 
data is encrypted MPEG4 data and that an expansion 10 
header has been added to the RTP header (step S903). 
Then at the expansion header receiver/interpreter 706 
it is learned that the expansion header is an encryption 
expansion header, and possible to learn from the en- 
cryption expansion header the encryption system and is 
whether or not there is updating of the encryption key 
(step S907). Then, similar to the case of the first embod- 
iment at the data encryptor/decryptor 707 the encrypted 
MPEG4 data is decrypted (step S909), and at the MPEG 
payload header receiver/interpreter 715 the MPEG4 20 
payload header is interpreted (step S910), and further, 
similar to the first embodiment, at the MPEG4 data gen- 
erator 706 MPEG4 data is decoded, based on the re- 
sults of the above interpreting, the results being output- 
tcd as an AV output data (for example, an analog signal). 2S 
[0105] In this second embodiment, in the case in 
which the payload type field is coded with information 
that includes notification of encryption, the encryption 
on/off field of the encryption expansion header need not 
be referenced, and in the case in which the payload type 30 
field is coded with information that includes notification 
of the encryption, this can be taken as a notification of 
the possibility of encryption, so that encryption on/off 
field in the encryption expansion header can be used for 
the final determination of whether or not there is encryp- 35 
tion. 

Third Embodiment 

[0106] Next, the third embodiment of the present in- 40 
vention is described in detail below, with reference to 
Fig. 16 and Fig. 17. In this embodiment, the description 
will focus on differences with respect to the second em- 
bodiment. 

[0107] The configuration and processing in the third 45 
embodiment are similar to those of the third embodi- 
ment. 

[0108] Fig. 16 shows the format of the RTP header 
format used in transmitting encrypted AV data in the 
third embodiment, and Fig. 17 shows the overall IP so 
packet format transferred via the Internet in the third em- 
bodiment. 

[0109] Specifically, whereas in the second embodi- 
ment, in the payload type field within the RTP basic 
header information was coded that provides notification ss 
of the existence of encryption or the possibility of en- 
cryption, such as "encrypted MPEG4 data", in the third 
embodiment, only "MPEG4" is coded, and information 



including notification of encrypting or the possibility 
thereof is not coded in the payload type field 
[0110] In the third embodiment, therefore, while the 
receiving apparatus 102 can refer to the payload type 
field to know that the received data is MPEG4 data, rec- 
ognition with regard to whether or not there is encryption 
is done by referencing the RTP expansion header (the 
encryption expansion header) of the RTP header. 
[0111] In the receiving apparatus 102, at the RTP ba- 
sic header receiver/interpreter 704 it is learned that the 
received data is MPEG4 data, and that an expansion 
header is added to the RTP header. Then, at the encryp- 
tion expansion header receiver/interpreter 706, it is 
learned that the expansion header is an encryption ex- 
pansion header, and it is possible to learn from the en- 
cryption expansion header whether or not there is en- 
cryption and whether or not the encryption key is updat- 
ed. Thereafter, the processing is the same as in the sec- 
ond embodiment. 

Fourth Embodiment 

[0112] Next, the fourth embodiment of the present in- 
vention is described below with reference to Fig. 18 to 
Fig. 23, focusing on the difference between it and the 
second embodiment. 

[0113] The difference between the f ou rth embodiment 
and the second embodiment is that, whereas in the sec- 
ond embodiment the encryption expansion header is 
added to the expansion header of the RTP header and 
the MPEG4 expansion header is provided as a payload 
header of the RTP payload (Fig. 11 and Fig. 12), in the 
fourth embodiment, both the encryption expansion 
header and the MPEG4 expansion header are provided 
as a payload header in the RTP payload (Fig. 19 and 
Fig. 20). 

[0114] The overall configuration of a network accord- 
ing to the fourth embodiment is similar to that of an 
above-noted embodiment (Fig. 1 ), and the processing 
sequence is also similar to an above-noted embodiment 
(Fig. 2). The format of the encryption expansion header 
(encryption payload header in the fourth embodiment) 
is also the same as described above (Fig. 5). 
[0115] Fig. 18 shows an example of the configuration 
of an MPEG4 distribution server 101 according to the 
fourth embodiment. In this embodiment, because the 
encryption expansion header added to the MPEG4 ex- 
pansion header is also provided as a payload header in 
the RTP payload, the processing for the encryption ex- 
pansion header is placed outside the RTP processor, 
and the encryption expansion header adding unit 304 of 
Fig. 10 is also moved from within the RTP processor 304 
to outside, this serving as the encryption payload header 
adding unit 31 4, which is a difference with respect to the 
second embodiment. 

[0116] Fig. 21 is a flowchart showing the procedure 
for content distribution processing according to the 
fourth embodiment. In the fourth embodiment, in place 
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of step S403 of Fig. 13, an encryption payload header 
adding unit 314 adds an encryption payload header to 
the encrypted MPEG4 data (step 403b). The processing 
at other steps S400, S401. S407, and S409 are similar 
to that described with regard to the above embodiment, 5 
with the exception that the above-noted information is 
set into the header. 

[0117] Fig. 19 shows the format of the RTP header 
used in transmission of encrypted AV data in the fourth 
embodiment. With regard to the payload type field, the 10 
fourth embodiment is similar to the second embodiment. 
The function of the X bit field is similar to that in the sec- 
ond embodiment, and in this embodiment the arrange- 
ment is that a bit indicating "no expansion header (no 
RTP expansion header)" is set. is 
[0118] Fig. 20 shows the overall format of an IP packet 
transferred via the Internet in the fourth embodiment. 
[0119] Fig. 22 shows an example of the configuration 
of a receiving apparatus 1 02 according to the fourth em- 
bodimenl. Similar to the case of the above-noted 20 
MPEG4 distribution server 101, the processing of the 
encryption expansion header is moved to outside the 
RTP processor, and the encryption expansion header 
receiver /interpreter 706 of Fig. 11 is moved from within 
the RTP processor 703 to outside, this serving as the 2s 
encryption payload header receiver/interpreter 716, 
which is a difference with respect to the second embod- 
iment. 

[0120] Fig. 23 shows the procedure for receiving 
processing in the receiving apparatus 102 in the fourth 30 
embodiment. In the receiving apparatus 102, first a 
packet is received (step S901), and at the RTP basic 
header receiver/interpreter 704 it is learned that the re- 
ceived data is encrypted MPEG4 data, and learned that 
no expansion header is added to the RTP header (step 35 
S903). In this embodiment, subsequent processing is 
processing for the payload. First at the encryption pay- 
load receiver/interpreter 716 it is learned that the pay- 
load is an encryption expansion header, and it is also 
possible to learn from the encryption payload header 40 
such information as the encryption system and whether 
the encryption key is updated (step S907b). Subsequent 
processing is similar to the case of the second embod- 
iment, the encrypted MPEG4 data being decrypted at 
the data encryptor/decryptor 707 (step S909), the 45 
MPEG4 payload header being interpreted at the 
MPEG4 payload header receiver/interpreter 71 5 (step 
S910), the MPEG4 data being decoded at the MPEG4 
data generator 708, based on the above interpretation 
results, and the results of this being output as an AV so 
output data (for example, an analog signal). 
[01 21 ] Similar to the case of the second embodiment, 
in the fourth embodiment in a case in which information 
including notification of encryption is coded into the pay- 
load header, it is not necessary to refer to the encryption 55 
on/off field of the encryption payload header, and if in- 
formation including notification of encryption is coded in- 
to the payload type field, this can be taken as a notifica- 



tion of the possibility of encryption so that the encryp- 
tion on/off field of the encryption payload header can be 
used for the final determination of whether or not there 
is encryption. 

Fifth Embodiment 

[0122] Next, the fifth embodiment of the present in- 
vention is described below, with reference to Fig. 24 
through Fig. 26, the description thereof focusing on the 
difference with respect to the second embodiment. 
[0123] Fig. 24 shows the format of the RTP header 
used when transmitting encrypted AV data in the fifth 
embodiment. Fig. 25 shows the format of the encryption 
expansion header in the fifth embodiment, and Fig. 26 
shows the overall IP packet transferred via the Internet 
in the fifth embodiment. 

[0124] Whereas in the second embodiment informa- 
tion including notification of encrypted data attributes 
(for example, encoding system) such as "encrypted 
MPEG4" was coded into the payload type field within 
the RTP basic header (Fig. 11 and Fig. 12), in the fifth 
embodiment only information giving notification of the 
fact that the data is encrypted (for example, "encrypted 
data") is coded into the payload type header (Fig. 24 
and Fig. 26). While the addition of an encryption expan- 
sion header as an expansion header to the RTP header, 
and the provision of an MPEG4 expansion header as a 
payload header to the RTP payload are the same as 
with the second embodiment, in the fifth embodiment 
the above-noted encrypted data attributes (encoding 
system or the like) are coded into the encryption expan- 
sion header (Fig. 5 and Fig. 25). 
[0125] The overall configuration of the network ac- 
cording to the fifth embodiment is similar to that of an 
above-noted embodiment (Fig. 1 ), and the sequence of 
processing is also similar to an above-noted embodi- 
ment (Fig. 2). The internal configurations of the MPEG4 
distribution server 101 and the receiving apparatus 102 
are also similar to those of the second embodiment (Fig. 
11 and Fig. 13). 

[0126] As shown in Fig. 24, in the fifth embodiment a 
value indicating "encrypted data" is coded into the pay- 
load type field of the RTP basic header. The receiving 
apparatus 1 02 can refer this field to learn that the trans- 
ferred data is encrypted. In the fifth embodiment, the X 
bit field has a bit that indicates "there is an expansion 
header". 

[0127] As shown in Fig. 25, in the fifth embodiment, a 
payload type field is provided in the encryption expan- 
sion header. Information indicating the type of data 
(MPEG4 in this embodiment) in the payload is coded 
into the payload type field. The receiving apparatus 102 
can refer to this field to learn the type of data transferred. 
[0128] In the receiving apparatus 102, at the RTP ba- 
sic header receiver/interpreter 704 it is learned that the 
received data is encrypted data, and that there is an ex- 
pansion header added to the RTP header. Then, at the 
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encryption expansion header receiver/interpreter 706 is 
it learned that this expansion header is an encryption 
expansion header, and from the encryption expansion 
header it is possible to learn such information as the en- 
cryption system, whether or not the encryption key is 
updated, and the type of data in the payload. Similar to 
the case of the second embodiment, the encrypted 
MPEG4 data is decrypted at the data enc ryptor/d eery p- 
tor 707, the MPEG4 payload header is interpreted at the 
MPEG4 payload header receiver/interpreter 715, at the 
MPEG4 data generator -the MPEG4 data is decoded 
based on the results of the above interpretation, and the 
results are output as an AV output data (for example, an 
analog signal). 

[0129] In the fifth embodiment, similar to the case of 
the second embodiment, in the case in which informa- 
tion including notification of encryption is coded into the 
payload type field, it is not necessary to refer to the en- 
cryption on/oft field of the encryption expansion header, 
and if information including notification of encryption is 
coded into the payload type field in the RTP basic head- 
er, this can be taken as a notification of the possibility 
of encryption, so that the encryption on/off field of the 
encryption expansion header can be used for the final 
determination of whether or not there is encryption. 

Sixth Embodiment 

[0130] Next, the sixth embodiment of the present in- 
vention is described below with reference to Fig. 27 and 
Fig. 28, the description focusing on the difference with 
respect to the fourth embodiment. 
[0131] Fig. 27 shows the format of the RTP header 
used when transmitting encrypted AV data in the sixth 
embodiment. The encryption expansion header of this 
embodiment is similar to that shown in Fig. 25. Fig. 28 
shows the overall format of an IP packet transferred via 
the Internet in the sixth embodiment. 
[0132] That both the encryption expansion header 
and the MPEG4 expansion header are provided as an 
RTP payload header is similar to the fourth embodiment 
(Fig. 19 and Fig. 20). However, in contrast to the fourth 
embodiment, wherein information including notification 
of attributes of encrypted data, such as the encoding 
system, for example, "encrypted MPEG4" are coded in- 
to the payload type field within the RTP basic header, in 
the sixth embodiment, only information giving notifica- 
tion about the existence of encryption (such as "encrypt- 
ed data") is coded into the payload type field (Fig. 27 
and Fig. 28). Additionally, while the fact that an encryp- 
tion expansion header is added as an expansion header 
of the RTP header, and an MPEG4 expansion header 
is added as a payload header to the RTP payload are 
the same as in the second embodiment, in the sixth em- 
bodiment the above-noted encrypted data attributes (for 
example, encoding system) are coded within the en- 
cryption expansion header (Fig. 5 and Fig. 25) 
[0133] The overall configuration of the network ac- 



cording to the sixth embodiment is similar to an above- 
noted embodiment (Fig 1), and the sequence of 
processing is also similar to an above-noted embodi- 
ment (Fig. 2). The internal configuration of the MPEG4 
5 distribution server 101 and the receiving apparatus 102 
are also similar to those of the fourth embodiment (Fig. 
18 and Fig. 22). 

[0134] As shown in Fig. 27, in the sixth embodiment 
a value indicating "encrypted data" is entered into the 
io payload type field of the RTP basic header. By referring 
to this field, the receiving apparatus 102 can know that 
the transferred data is encrypted data. The X bit field 
has a bit that indicates "there is no expansion header". 
Similar to the case of the fourth embodiment, informa- 
is tion indicating the type of data in the payload (MPEG4 
in this embodiment) is coded into the payload type field 
of the encryption expansion header. 
[01 35] In the receiving apparatus 1 02, at the RTP ba- 
sic header receiver/interpreter 704 it is learned that the 

20 received data is encrypted, and it is learned that no ex- 
pansion header is added to the RTP header. In the sixth 
embodiment, subsequent processing is with respect to 
the payload. First, at the encryption payload receiver/ 
interpreter 716 it is learned that the payload header is 

25 an encryption expansion header, and it is possible to 
learn from the encryption payload head such informa- 
tion as the encryption system, whether the encryption 
key is updated, and type of data in the payload. In the 
same manner as in the fourth embodiment, at the data 

30 encryptor/decryptor 707 the encrypted MPEG4 data is 
decrypted, at the MPEG payload header receiver/inter- 
preter 71 5 the MPEG4 payload header is interpreted, at 
the MPEG4 data generator 708 the MPEG4 data is de- 
coded based on results of the above interpretation, the 

35 results being output as an AV output data (for example, 
an analog signal). 

[01 36] In the sixth embodiment, similar to the case of 
the fourth embodiment, in the case in which information 
including notification of encryption is coded into the pay- 

40 bad type field of the RTP basic header, it is not neces- 
sary to refer to the encryption on/off field in the encryp- 
tion expansion header and if information including no- 
tification of encryption is coded into the payload type 
field, this can be taken as a notification of the possibility 

45 of encryption, so that the encryption on/off field of the 
encryption expansion header can be used for the final 
determination of whether or not there is encryption. 



so 



Seventh Embodiment 



[0137] Whereas in the first embodiment to the sixth 
embodiment, the present invention was applied to a sys- 
tem in which RTP was used as a transport protocol, the 
present invention can also be applied to systems using 
55 other protocols. 

[0138] In the seventh embodiment, instead of using 
RTP as the transport protocol, the distribution of MPEG4 
data is performed using HTTP (Hyper-Text Transfer Pro- 
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tocol), that is, a protocol for use between WWW servers 
and Web browsers. 

[01 39] Fig. 29 shows an example of the configuration 
of an information distribution system in the seventh em- 
bodiment. In system shown in Fig. 29, an MPEG4 dis- 
tribution server 6101 according to the seventh embodi- 
ment is connected to the Internet 103, and a receiving 
apparatus 6102 according to the seventh embodiment 
is connected to a LAN 6105, the LAN 6105 being con- 
nected to the Internet 103 via a proxy server 6104. The 
receiving apparatus 6102 performs AV stream commu- 
nication secretly with the MPEG4 distribution server 
6101 , via the LAN 6105, the proxy server 6104 and the 
Internet 103. Of course, other MPEG4 distribution serv- 
ers and other types of equipment can also be connected 
to the Internet 1 03, and other receiving apparatuses and 
other types of equipment can also be connected to the 
LAN 6105 

[0140] Although in the seventh embodiment, the de- 
scription is thai of the case in which the data type is 
MPEG4 it will be understood, of course, that the present 
invention is not restricted to this type of data. 
[0141] In Fig 29, the various equipment supports IP. 
However because of the HTTP proxy server 6104 be- 
tween the LAN 6105 and the Internet 103, the IP ad- 
dress on the LAN 61 05 can be either a global IP address 
or a private (local) IP address. The term proxy server as 
used herein refers to a server that at one point termi- 
nates HTTP (or some other protocol) between the Inter- 
net and an intranet, and functions so as to join HTTP 
sessions at both ends of the proxy server, and is provid- 
ed to enable the distribution of HTTP content data re- 
quested by substantial receiving apparatus (Web 
browser) to a distribution server (Web server) : and func- 
tions in the reverse direction as well. Details about proxy 
servers can be found at, for example, the URL http:// 
squid, nianr net/Squid. In the seventh embodiment, the 
MPEG4 distribution server 61 01 can be a WWW server, 
and the receiving apparatus 61 02 can also be a browser. 
[0142] Fig 30 shows an example of the sequence of 
the authentication process, key exchange process, and 
encrypted data transmission. Because the proxy server 
6104 is disposed between the receiving apparatus 61 02 
and the MPEG4 distribution server 6101, the actual 
messages (messages transferred as HTTP messages) 
are in reality relayed via the proxy server 6104, this be- 
ing the only difference with respect to previously de- 
scribed embodiments (Fig. 2), with other elements of the 
procedure being the same as previously described pro- 
cedures. 

[0143] With regard to the MPEG4 distribution server 
6101, the receiving apparatus 6102, the packet format, 
if parts of the units in the first through the sixth embod- 
iments dependent upon the transport protocol are mod- 
ified to accommodate the HTTP protocol, it is possible 
to configure an MPEG4 distribution server 6101, a re- 
ceiving apparatus 6102, and a packet format conform- 
ing to the HTTP protocol. In the following, the example 



is that in which an encryption expansion header is added 
as an expansion header, and in which an MPEG4 ex- 
pansion header is provided as a payload header (as in 
the second embodiment). 

5 [0144] Fig. 31 shows the internal configuration of the 
MPEG4 distribution server 6101 . 
[0145] As shown in Fig. 31, the MPEG4 distribution 
server 6101 according to the seventh embodiment com- 
prises an MPEG4 data generator 6301 , a data encrypter 

io 6302, an MPEG4 payload header adding unit 6305, an 
HTTP processor 6303 that includes an encryption head- 
er adding unit 6304 and a MIME header adding unit 
6306, a TCP/IP and UDP/IP processor 6308, a link/ 
physical layer processor 6309, and an authentication/ 

is key exchange processor 6311 . 

[0146] Processing related to authentication and en- 
cryption of the sequence shown in Fig. 30 (from S6201 
to S6205) and processing related to encryption key up- 
dating is performed by the authentication/key exchange 

20 processor 6311. 

[01 47] The HTTP processor 6303 corresponds to the 
RTP processor in previously described embodiments, 
and the MIME (Multipurpose Internet Mail Extensions) 
header adding unit 6306 corresponds to the RTP basic 

25 header adding unit in previously described embodi- 
ments. 

[0148] Fig. 32 shows an IP packet that is transferred 
on the Internet (and LAN), and Fig. 33 shows details of 
the MIME basic header and encryption expansion head- 

30 er 

[01 49] In the seventh embodiment, the encryption ex- 
pansion header is transferred as part of the MIME. For 
this reason, with regard to the encryption expansion 
header, information indicating that this is an encryption 

3S expansion header" is coded into the Content-Type of the 
MIME. The MPEG4 expansion header is transferred as 
part of the Ml ME, along with the encrypted MPEG4 data 
as payload header. For the encrypted MPEG4 data to 
which MPEG4 expansion header added, information in- 

40 dicating that "this is MPEG4 data" is coded into the 
MIME Content-Type. For details with regard to MIME, 
refer to RFC 2045, for example. 
[01 50] The format of the encryption expansion header 
is the same as was described for the first embodiment. 

45 [0151] Fig. 34 shows an example of the internal con- 
figuration of the receiving apparatus 6102. 
[0152] As shown in Fig. 34, the receiving apparatus 
6102 according to the seventh embodiment comprises 
a link/physical layer processor 6701, a TCP/IP and 

so UDP/IP processor 6702, an HTTP processor 6703 that 
includes a MIME header interpreter 6704 and an en- 
cryption header interpreter 6706, an MPEG4 payload 
header interpreter. 6705, a data encryptor/decryptor 
6707, an MPEG4 data decoder 6708, and an authenti- 

ss cation/key exchan ge processor 67 1 1 . 

[0153] Processing related to authentication and en- 
cryption in the sequence of Fig. 30 (processing from 
S6201 to S6205) and processing related to encryption 
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key updating is performed by the authentication/key ex- 
change processor 6711 . 

[01 54] The HTTP processor 6703 corresponds to the 
RTP processor shown in the above-described embodi- 
ments, and the MIME header interpreter 6704 corre- s 
sponds to the RTP basic header receiver/interpreter in 
the above-described embodiments. 
[0155] In the MPEG4 distribution server 6101 , the in- 
putted AV content (for example, an analog signal) is 
compressed to MPEG4 data by the MPEG4 data gen- 10 
erator 6301 . Required information is sent as notification 
to the MPEG4 payload header adding unit 6305 from 
the MPEG4 data generator 6301 . 
[0156] Next, the MPEG4 data outputted from the 
MPEG4 data generator 6301 is encrypted by the data is 
encrypter 6302. The encryption key used when doing 
this is the above-described time-variant encryption key 
Kc. Required information is sent as notification to the 
encryption header adding unit 6304 from the data en- 
crypler 6302. 20 
[0157] Next, in the HTTP processor 6303, at the en- 
cryption header adding unit 6304. the encryption expan- 
sion header is added, and at the MIME header adding 
unit 6306, a MIME header is added. 

[0158] Encrypted MPEG4 data to which has been 25 
added a MIME header is sent as a packet shown in Fig. 
32 to the Internet 6103 by the TCP/IP and UDP/IP proc- 
essor 6308, via the link/physical layer processor 6309. 
[0159] In the receiving apparatus 6102, at the MIME 
header interpreter 6704, it is learned that there is a pos- 30 
sibility that the received data is encrypted, and that an 
encryption expansion header is added as part of the 
MIME. At the encryption header interpreter 6706 it can 
be learned from the encryption expansion header 
whether or not encryption is present, the encryption sys- 35 
tern and whether the encryption key is updated. In the 
same manner as in the case of the second embodiment, 
the data encryptor/decryptor 6707 decrypts the encrypt- 
ed MPEG4 data, at the MPEG4 payload header inter- 
preting section 671 5 the MPEG4 payload header (sim- 40 
ilar to the MPEG4 payload header in previously de- 
scribed embodiments) is interpreted, and at the MPEG4 
data generator 6708 the MPEG4 data is decoded based 
on the results of the above interpretation, the result be- 
ing output as an AV output data (tor example, an analog *s 
signal). 

[0160] In the above, the encryption expansion header 
is added as an expansion header and Ihe MPEG4 ex- 
pansion header was provided as a payload header on 
the payload. However, it is also possible to use a differ- so 
ent configuration, for example one in which the encryp- 
tion expansion header and MPEG4 expansion header 
arc added as an expansion header, or in which the en- 
cryption expansion header and MPEG4 expansion 
header are provided as a payload header on the pay- ss 
load. 

[0161] While in the first to seventh embodiments an 
Even/Odd field in the encryption expansion header (or 



encryption payload header) was used to notify the re- 
ceiving side from the sending side of updating of the var- 
iable value Nc used for generating the encryption key 
Kc, instead of using the Even/Odd field, it is possible to 
send the value of Nc, in which case the Nc value can be 
randomly generated, as opposed to simply being incre- 
mented. The value of Nc can also be changed for each 
individual packet. 

[0162] While in the first to seventh embodiments RTP 
or HTTP was used as the transfer protocol, it will be un- 
derstood that other protocols can also be used, and fur- 
ther that the network to which the present invention is 
applied is not limited to the Internet. For example, any 
kinds of local area network, such as Bluetooth, can use 
the methods of this invention. Further, the present in- 
vention has no restriction in application to the case in 
which the transferred data is MPEG4 data. 
[0163] Although in the second, third, and fifth embod- 
iments, the data encryptor 302 and data encryptor/de- 
cryptor-707 were provided outside the RTP processors 
303 and 307, these can alternately be provided within 
the RTP processors 303 and 307. 

Eighth Embodiment 

[01 64] Next, the eighth embodiment of the present in- 
vention is described below with reference to Fig. 35. 
[0165] Whereas in the first to the seventh embodi- 
ments, the description was for the sequence shown in 
Fig. 2, it is understood that the present invention can be 
applied to other sequences as well. 
[0166] The description that follows is for other se- 
quences, for the case in which MPEG4 data distributed 
from an MPEG4 distribution server is stored by the re- 
ceiving apparatus. 

[0167] The configuration of the information distribu- 
tion system according to the eighth embodiment is sim- 
ilar to that shown in Fig. 1. In Fig. 1, an MPEG4 distri- 
bution server 101 and a receiving apparatus 102 ac- 
cording to the eighth embodiment are connected to the 
Internet 103, MPEG4 AV stream data being secretly 
communicated between the MPEG4 distribution server 
101 and the receiving apparatus 102, via the Internet 
103. Of course, other MPEG4 distribution servers and 
receiving apparatuses and other types of equipment can 
additionally be connected to the Internet 103. 
[0168] In the description of the eighth embodiment, 
while the type of data is MPEG4, it will be understood 
that the eighth embodiment is not restricted to applica- 
tion to this type of data, and can be applied to other data 
types as well. 

[0169] The MPEG4 distribution server 101 performs 
distribution of MPEG4 data to the receiving apparatus 
102. MPEG4 data is distributed not in the form of file 
transfer, but rather as a stream. When this is done, the 
MPEG4 data that is to be copyright protected is distrib- 
uted in encrypted form Before distribution, an authen- 
tication procedure or key exchange procedure is per- 
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formed between the MPEG4 distribution server 101 and 
the receiving apparatus 102. 

[0170] An example of the sequence used is shown in 
Fig. 35. 

[0171] In Fig. 35 shows the sequence of content layer 
encryption and authentication, and it should be noted 
that security in layers such as the IP layer and transport 
layer and authentication procedures in those layers 
have been omitted from this drawing, as has the proce- 
dure for assessing charges at the content layer, which 
is performed earlier (although there are cases in which 
charge assessment and authentication/encryption at 
other layers are not performed). 

[01 72] Similar to the case ol the first embodiment; the 
MPEG4 distribution server 101 and the receiving appa- 
ratus 1 02 perform authentication and exchange of a cer- 
tificate (equipment certificate) (S7201, S7202). 
[0173] The MPEG4 distribution server 101 must notify 
the receiving apparatus 1 02 of the encryption key Kc for 
decrypting the content (AV data that is sent), and the 
following measure is taken to prevent the unlimited un- 
authorized copying of the content at the receiving appa- 
ratus 102. Specifically, when performing storage onto a 
storage medium (for example, a DVD-RAM) of the re- 
ceiving apparatus 1 02, AV data is stored in encrypted 
form. When the data stored on the storage medium is 
to be played back, a check is made as to whether the 
data was properly stored on the storage medium and, if 
not, playback is not possible That is, if digital copying 
is done from this storage medium onto another storage 
medium (for example, onto another DV-RAM), playback 
is prevented from the copying destination medium. 
[0174] For this reason, notification of the MID, which 
is the ID (serial number) of the storage medium used at 
the receiving apparatus 102 is given from the receiving 
apparatus 102 to the MPEG4 distribution server 101 
(step S7203), and at the MPEG4 distribution server 1 01 
this MID value is used to encrypt the encryption key Kc 
and notify the receiving apparatus 102 (step S7204). 
More specifically, using a pre-established function g an 
encryption key W is generated of the form W=g(MID), 
and this encryption key W is used to encrypt the encryp- 
tion key Kc (the encryption key Kc encrypted by the en- 
cryption key W being represented as [Kc]w), [Kc]w being 
then transmitted. In this arrangement, the value of MID 
is unique to each individual storage medium, and is lo- 
cated in a region of ROM, for example, that cannot be 
overwritten. 

[01 75] Having received the above-noted [Kc]w, the re- 
ceiving apparatus 102 generates the encryption key W 
in the form W=g(MID), using the same function g that 
was used at the MPEG4 distribution server 101 , this en- 
cryption key W being used to decrypt [Kc]w so as to re- 
cover the encryption key Kc. 

[0176] Thereafter, at the MPEG4 distribution server 
101 MPEG4 data is generated from the AV data, and 
MPEG4 data is encrypted using the encryption key Kc 
shared as described above, the encrypted MPEG4 data 



being then transmitted to the receiving apparatus 102 
(step S7206). 

[0177] At the receiving apparatus 102, the received 
encrypted MPEG4 data is decrypted using the encryp- 
s tion key Kc determined as noted above and decrypted 
MPEG4 data is decoded, resulting in output of an AV 
output data. 

[0178] In the eighth embodiment the receiving appa- 
ratus 102 has a function which, simultaneously with re- 

10 ceiving the AV data (MPEG4 data encrypted with the 
encryption key Kc), or after entering it into a buffer or 
the like, stores the received AV data in the form of 
MPEG4 data encrypted using the encryption key Kc, 
along with the value of [Kc]w, onto a storage medium 

is having the above-noted MID. 

[0179] When the above is done, an apparatus for 
playing back the AV data (MPEG4 data encrypted with 
the encryption key Kc) stored on the proper storage me- 
dium (which can be the receiving apparatus 102, or an- 

20 other equipment) first reads the values of [Kc]w and MID 
from the storage medium, and then generates the en- 
cryption key W in the form W=g(MID), this encryption 
key W being used to decrypt [Kc]w so as to recover the 
encryption key Kc. Then the AV data (MPEG4 data en- 

25 crypted by the encryption key Kc) stored on the storage 
medium is read out and, after decrypting with the en- 
cryption key Kc, the decrypted MPEG4 data is decoded. 
[0180] If AV data (MPEG4 data encrypted by the en- 
cryption key Kc) recorded on a storage medium having 

30 a given MID of MIDI is copied onto a storage medium 
having a MID of MID2, at the equipment that plays back 
the data recorded on the copy destination storage me- 
dium, because it is not possible to obtain the original 
Ml D value, it is not possible to generate W, and therefore 

35 not possible to determine the encryption key Kc from the 
recorded [Kc]w. As a result, it is not possible to decrypt 
the recorded encrypted data. 

[0181] That is, if proper values of Kc, W, and [Kc]w 
are Kcl, W1 =g(MIDl ), and [Kc]wl, because the Ml D read 

40 out Irom the copy destination storage medium is MID2, 
the encryption key W generated therefrom is W2=g 
(MID2) and if the [Kc]wl read from the storage medium 
is decrypted using W2. a value that is different from Kc 
results (this being called Kc*). Therefore, an attempt to 

45 decrypt data [Data]Kc encrypted with Kc using Kc' will 
result in generation of Data', which is different from the 
original data Data, making it impossible to recover the 
original data Data. 

[0182] Thus, even if the received AV data (MPEG4 
so data encrypted by the encryption key Kc) is copied onto 
a different storage medium, because the value of MID 
of that storage medium is different, it is possible to pre- 
vent playback of the AV data, thereby enabling preven- 
tion of unauthorized copying. 
55 [0183] In the eighth embodiment, the RTP header, en- 
cryption expansion (pay load) header, and MPEG4 ex- 
pansion (pay load) header and the like can have the 
same format as described with regard to the first through 
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the seventh embodiments. 

[0184] Although the above-noted description is for the 
case in which MPEG4 was used as the encoding sys- 
tem, it will be understood that the present invention can 
be applied to other encoding systems as well, in which s 
case it is merely necessary to modify the constituent el- 
ements of each of the embodiments (for example, the 
MPEG4 data generator, the MPEG4 expansion header 
adding unit, the MPEG4 data decoder, the MPEG4 ex- 
pansion header receiver/interpreter, and the like), the 10 
expansion header (MPEG4 expansion header and 
MPEG4 payload header), and the payload type coding 
to suit the selected type of encoding system. 
[0185] The distribution server of the described em- 
bodiments, if necessary, can also be made to send con- is 
tent in unencrypted form. That is, the coding of the en- 
cryption on/off field and payload type field and the like 
can be established as appropriate to the existence or 
non-existence of encryption. The receiving side as well 
can check for the presence of encryption from the head- 20 
er of a received packet, and control decryption process- 
ing accordingly. 

[0186] The transport protocol used in the foregoing 
embodiments includes at least RTP or HTTP. 
[0187] The present invention can also be embodied 2S 
as a method and a method according to the present in- 
vention can be embodied as an apparatus. Additionally, 
the functions of the present invention can be embodied 
as software as well. 

[0188] The present invention embodied as either an 30 
apparatus or a method can be further embodied as a 
computer-readable storage medium for storage of a pro- 
gram to be executed by a computer, following a proce- 
dure corresponding to the present invention (or a pro- 
gram for causing a computer to function as ameans cor- 35 
responding to the present invention or a program for im- 
plementing the functions of the present invention with a 
computer). That is, a program for the purpose of imple- 
menting the processing for content distribution and re- 
ceiving according to the present invention can be stored 40 
onto various types of storage media. The storage medi- 
um is then read by the CPU of a computer implemented 
in hardware, and the stored program is then executed 
to embody the present invention. The term storage me- 
dium used herein can be taken as referring to semicon- 45 
ductor memory, magnetic disk (floppy disk or hard disk), 
optical disk (CD-ROM or DVD or the like), and any other 
medium that can be used to store a program. Addition- 
ally, the program can be distributed by various commu- 
nications means, such as a network. so 
[0189] In summary, according to the present invention 
an encryption expansion header is provided in the form 
of a expansion header or payload header in a transport 
protocol such as RTP (Real-time Transport Protocol) or 
HTTP (Hyper-text Transfer Protocol), and encryption at- ss 
tribute information with regard to encryption is coded in- 
to this encryption expansion header (for example, pres- 
ence of encryption, encryption system, information with 



regard to copying (encryption mode indicator: EMI), in- 
formation (Even/Odd field) on which to base generation 
of a content key (common key) and the like), and by do- 
ing so content data is sent securely from the sending 
side to the receiving side, and it is possible at the re- 
ceiving side to decrypt the encrypted content data trans- 
ferred as a payload. 

[0190] In RTP in the past, only the type of encoding 
system used with data of the payload was coded in the 
payload type field, so that in the case in which the data 
stored in the payload was encrypted not in at the net- 
work or transporter layer, but rather at the content layer, 
there was no method of giving notification of this to the 
other side. 

[0191] On the other hand, with the present invention, 
because coding is provided in the RTP payload type 
field to the effect that the content is "encrypted data" or 
"encrypted data encoded by a specific encoding sys- 
tem", it is possible to give notification of this to the other 
side, thereby enabling sufficient copy protection in send- 
ing and receiving encrypted content as described 
above. 

[0192] According to the present invention as de- 
scribed above, it is possible to expand the distribution 
of digital content, providing copy protection for AV 
streaming that covers not only IEEE 1 394, but also net- 
works such as the Internet and LAN. 
[0193] It is to be noted that, besides those already 
mentioned above, many modifications and variations of 
the above embodiments may be made without departing 
from the noel and advantageous features of the present 
invention. Accordingly, ail such modifications and vari- 
ations are intended to be included within the scope of 
the appended claims. 



Claims 

1 . A content information distribution apparatus for dis- 
tributing encrypted content information, via a net- 
work in accordance with a prescribed transport pro- 
tocol, to other end apparatus in a communication 
authenticated by an authentication process includ- 
ing at least one procedure of an authentication pro- 
cedure and a key exchange procedure, comprising: 

(a) a unit (302) for encrypting content informa- 
tion encoded by a prescribed encoding system; 

(b) aunit (304) for generating an encryption at- 
tribute header including attribute information 
with regard to the encryption of the content in- 
formation; 

(c) aunit (306) for performing transport protocol 
processing required to transfer the content in- 
formation and for generating a basic transport 
header to be added to the content information 
to which the encryption attribute header has 
been added; and 
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(d) a unit (309) for sending to the other end ap- 
paratus that is authenticated a packet including 
the basic transport header, the encryption at- 
tribute header, and the encrypted content infor- 
mation, wherein the encryption attribute header 
is set into an expansion transport header within 
a packet header of the packet or into a payload 
header within a payload to be encrypted of the 
packet. 

2. The apparatus according to claim 1 , wherein the en- 
cryption attribute header includes at least one of the 
existence or non-existence of encryption of the con- 
tent information and the encryption system of the 
content information. 

3. The apparatus according to claim 1 , wherein the en- 
cryption attribute header includes a copy attribute 
field having a plurality of bits with regard to the 
number ol copying of the content information. 

4. The apparatus according to claim 1 , wherein the en- 
cryption attribute header includes a counter field in- 
dicating a change in an encryption key. 

5. The apparatus according to claim 1, wherein the 
unit (b) sets the encoding information, which indi- 
cates the encoding system for the content informa- 
tion into the expansion transport header or into the 
payload header 

6. The apparatus according to claim 1 , wherein the 
unit (c) further codes into the basic transport header 
at least information indicating that there is a possi- 
bility that the content information is encrypted, and 
wherein the unit (b) codes into the expansion head- 
er at least information as to whether or not the con- 
tent information to be transferred is encrypted. 

7. The apparatus according to claim 1 , wherein the 
unit (b) codes into the expansion header informa- 
tion as to whether or not the content information to 
be transferred is encrypted. 

8. The apparatus according to claim 1 , further com- 
prising: 

(e) a (305) unit for generating a content at- 
tribute header that includes content attribute infor- 
mation with regard to content information, and for 
setting this content attribute header into the expan- 
sion transport header or into the payload header. 

9. The apparatus according to claim 8, wherein the 
content attribute header is not encrypted. 

10. The apparatus according to claim 1, wherein the 
unit (a) generates the encryption key based on an 
identifier that uniquely identifies a storage medium 



sent from the other end apparatus in a communica- 
tion. 

11. A content information receiving apparatus authen- 
s ticated by an authentication process including at 

least one procedure of an authentication procedure 
and a key exchange procedure and which receives 
encrypted content information via a network in ac- 
cordance with a prescribed transport protocol, com- 
10 prising: 

(aa) a unit (701) for receiving from a sending 
apparatus a packet containing a basic transport 
header, an encryption attribute header includ- 
es ing attribute information with regard to the en- 
cryption of the content information, and en- 
crypted content information; 
(bb) a unit (703) for referring to the basic trans- 
port header or encryption attribute header and 
20 judging whether or not the content information 
is encrypted or whether there is a possibility 
that the content information is encrypted; and 
(cc) a unit (707) that, when a judgment is made 
by the unit (bb) that the content information is 
25 encrypted, decrypts the encrypted content in- 
formation, based on the attribute information 
with regard to encryption included in the en- 
cryption attribute header. 

30 12. The apparatus according to claim 11, wherein the 
unit (bb), when there is a possibility that the content 
information is encrypted, refers to the encryption at- 
tribute header and judges whether or not the con- 
tent information is encrypted. 

35 

13. The apparatus according to claim 11, wherein the 
unit (bb) refers to the basic transport header or to 
the encryption attribute header to make a judgment 
as to the encoding system of the content informa- 

40 tion. 

14. The apparatus according to claim 11, further com- 
prising: 

(dd) a unit (709,71 0),for referring to a received 
45 basic transport header and, when a prescribed de- 
lay time has elapsed or a prescribed number of 
packets have been discarded, requesting that the 
sending apparatus send a prescribed encryption 
parameter 

so 

15. A method of distributing encrypted content informa- 
tion, via a network in accordance with a prescribed 
transport protocol, to other end apparatus in a com- 
munication authenticated by an authentication 

55 process including at least one procedure of an au- 
thentication procedure and a key exchange proce- 
dure, comprising the steps of: 
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(a) encrypting content information encoded by 
a prescribed encoding system (S401); 

(b) adding an encryption attribute header in- 
cluding attribute information with regard to the 
encryption of the content information to the en- s 
crypted content information (S403); 

(c) adding a content attribute header indicating 
attributes of the content information to content 
information to which the encryption attribute 
header has been added (S405); 10 

(d) performing transport protocol processing re- 
quired to transfer the content information, and 
adding a basic transport header to content in- 
formation to which the content attribute header 
has been added (S407); and is 

(e) sending a packet including the basic trans- 
port header, the encryption attribute header, 
the content attribute header and the encrypted 
content information to the other end authenti- 
cated apparatus (S409), 20 

wherein the encryption attribute header is set 
into either an expansion transport header within a 
packet header of the packet, or into a payload head- 
er within an encrypted payload of the packet. 25 

1 6. A method of distributing encrypted content informa- 
tion, via a network in accordance with a prescribed 
transport protocol, to other end apparatus in a com- 
munication authenticated by an authentication 30 
process including at least one procedure of an au- 
thentication procedure and a key exchange proce- 
dure, comprising the steps of: 

(a') adding a content attribute header indicating 35 
attributes of the content information to the con- 
tent information to be transferred (S400); 
(b') encrypting content information that are en- 
coded by a prescribed encoding system and to 
which the content attribute header has been 40 
added (S401); 

(c') adding to the encrypted content information 
an encryption attribute header including attribu- 
tion information with regard to the encryption of 
the content information (S403); 45 
(d') performing transport protocol processing 
required to transfer the content information, 
and adding a basic transport header to content 
information to which the encryption attribute 
header has been added (S407); and so 
(e') sending a packet including the basic trans- 
port header, the encryption attribute header, 
the content attribute header, and the encrypted 
content information to the other end authenti- 
cated apparatus (S409), 55 

wherein the encryption attribute header is set 
into either an expansion transport header within a 



packet header of the packet or into a payload head- 
er within a payload to be encrypted of the packet. 

17. A method of receiving encrypted content informa- 
tion, via a network in accordance with a prescribed 
transport protocol, by an authentication process in- 
cluding at least one procedure of an authentication 
procedure and a key exchange procedure, compris- 
ing the steps of: 

(aa) receiving a packet including a basic trans- 
port header, an encryption attribute header in- 
cluding encryption attribute information with re- 
gard to the encryption of the content informa- 
tion, and encrypted content information (S901 ); 
(bb) referring to the basic transport header and 
judging whether or not the content information 
is encrypted or whether or not there is a possi- 
bility that the content information is encrypted 
(S903); 

(cc) referring to the encryption attribute header 
and extracting encryption attribute information 
with regard to encryption of the content infor- 
mation (S907); 

(dd) referring to an expansion transport header 
within a packet header of the packet and ex- 
tracting content attribute information with re- 
gard to the content information (S905): and 
(ee) in the case in which a judgment is made at 
(bb) that the content information is encrypted, 
decrypting the encrypted content information, 
based on the extracted encryption attribute in- 
formation (S909). 

18. A method of receiving encrypted content informa- 
tion, via a network in accordance with a prescribed 
transport protocol, by an authentication process in- 
cluding at least one procedure of an authentication 
procedure and a key exchange procedure, compris- 
ing the steps of: 

(aa 1 ) receiving a packet including a basic trans- 
port header, an encryption attribute header in- 
cluding encryption attribute information with re- 
gard to the encryption of the content informa- 
tion, and encrypted content information (S901 ); 
(bb') referring to the basic transport header and 
judging whether or not the content information 
is encrypted or whether or not there is a possi- 
bility that the content information is encrypted 
(S903); 

(cc') in the case in which a judgment is made 
at (bb 1 ) that the content information is encrypt- 
ed, referring to the encryption attribute header 
and extracting encryption attribute information 
with regard to the encryption of the content in- 
formation (S907): 

(dd 1 ) in the case in which a judgment is made 
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at (bo") that the content information is encrypt- 
ed, decrypting the encrypted content informa- 
tion based on the extracted encryption attribute 
information (S909): and 

(ee*) referring to an expansion transport header 5 
within a packet header of the packet and ex- 
tracting content attribute information with re- 
gard to the content information (S910). 

1 9. A computer-readable recording medium for record- 10 
ing a program to be executed by a computer, the 
program performing distribution of encrypted con- 
tent information : via a network in accordance with 

a prescribed transport protocol, to other end appa- 
ratus in a communication authenticated by an au- is 
thentication process including at least one proce- 
dure of an authentication procedure and a key ex- 
change procedure, the program comprising: 

(a) a module (304) for generating an encryption 20 
attribute header including attribute information 
with regard to encryption of the content infor- 
mation; 

(b) a module (306) for performing transport pro- 
tocol processing required to transfer the con- 2s 
tent information and for generating a basic 
transport header to be added to the content in- 
formation to which the encryption attribute 
header has been added; and 

(c) a module (309) for sending a packet includ- 30 
ing the basic transport header, the encryption 
attribute header, and the encrypted content in- 
formation to the other end authenticated appa- 
ratus, 

35 

wherein the encryption attribute header Is set 
either into an expansion transport header within a 
packet header of the packet or into a pay toad head- 
er within a payload to be encrypted of the packet. 

40 

20. A computer- readable recording medium for record- 
ing a program to be executed by a computer, the 
program performing receiving of encrypted content 
information, via a network in accordance with a pre- 
scribed transport protocol, by an authentication 45 
process including at least one procedure of an au- 
thentication procedure and a key exchange proce- 
dure, the program comprising: 

(aa) a module (701 ) for receiving from a send- so 
ing apparatus a packet including a basic trans- 
port header, an encrypt ion attribute header in- 
cluding attribute information with regard to en- 
cryption of the content information, and en- 
crypted content information; ss 
(bb) a module (703) for referring to the basic 
transport header or the encryption attribute 
header and judging whether or not the content 



823 A2 38 

information is encrypted or whether there is a 
possibility that the content information is en- 
crypted: and 

(cc) a module (707) for decrypting the encrypt- 
ed content information based on attribute infor- 
mation with regard to encryption included in the 
encryption attribute header, in the case in which 
a judgment is made by module (bb) that the 
content information is encrypted 
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